From: Joey Hess Date: Tue, 14 Oct 2025 15:48:32 +0000 (-0400) Subject: comment X-Git-Tag: archive/raspbian/10.20251029-1+rpi1~1^2~3^2~16 X-Git-Url: https://dgit.raspbian.org/%22http://www.example.com/cgi/%22/%22http:/www.example.com/cgi/%22?a=commitdiff_plain;h=8ec4839e9cdb45d36418f9bf56f05583203c5754;p=git-annex.git comment --- diff --git a/doc/todo/More_fine-grained_testremote_command/comment_1_d0d1406f9b1619b57908e62ac3200f69._comment b/doc/todo/More_fine-grained_testremote_command/comment_1_d0d1406f9b1619b57908e62ac3200f69._comment new file mode 100644 index 0000000000..8d61f17ac7 --- /dev/null +++ b/doc/todo/More_fine-grained_testremote_command/comment_1_d0d1406f9b1619b57908e62ac3200f69._comment @@ -0,0 +1,26 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2025-10-14T14:54:53Z" + content=""" +It would be possible to make `git-annex testremote` support the +command-line options of the underlying test framework (tasty). +`git-annex test` already does that, so has --list-test and --pattern. + +It's not as simple as just plumbing that up though, because testremote has +implicit dependencies in its test ordering. It has to do the `storeKey` +test before it can do the `present` test, for example. Those dependencies +would need to be made explict, rather than implicit. + +Explict dependencies, though, would also make it not really possible to run +most of the tests separately. Running testremote 5 times to run the listed +tests, if each run does the necessary `storeKey` would add a lot of overhead. + +Not declaring dependencies and leaving it up to the user to run testremote +repeatedly to run a sequence of tests in the necessary order would also +run into problems with testremote using random test keys which change every +time it's run, as well as it having an end cleanup stage where it removes +any lingering test keys from the local repository and the remote. + +This seems to be a bit of an impasse... :-/ +"""]] diff --git a/doc/todo/More_fine-grained_testremote_command/comment_2_de940a1c4ca0194582cd0ad449eefe28._comment b/doc/todo/More_fine-grained_testremote_command/comment_2_de940a1c4ca0194582cd0ad449eefe28._comment new file mode 100644 index 0000000000..94958c870e --- /dev/null +++ b/doc/todo/More_fine-grained_testremote_command/comment_2_de940a1c4ca0194582cd0ad449eefe28._comment @@ -0,0 +1,34 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2025-10-14T15:21:02Z" + content=""" +I don't know about the "--write-only" name, but I see the value in having a +way for testremote to check what a remote that is expected to only allow +read access does not allow any writes, as well as otherwise behaving +correctly. + +There are actually only two write operations, `storeKey` and `removeKey`. +Since `removeKey` is supposed to succeed when a key is not present, if +`storeKey` fails, then `removeKey` will succeed. But `removeKey` should +fail to remove a key that is stored on the remote. To test that, +the --test-readonly=file option would need to be used to provide a file +that is already stored on the remote. + +I think it would make sense to require that option be present +in order to use this new "--write-only" (or whatever name) option. + +--- + +Also, git-annex does know internally that some remotes are readonly. For +example, a regular http git remote that does not use p2phttp. +Or any remote that has `remote..annex-readonly` set. Currently +`testremote` only skips all the write tests for those, rather than +confirming that writes fail. It would make sense for testremote of a known +readonly remote to behave as if this new option were provided. + +(But, setting `remote..annex-readonly` rather than using +the "--write-only" option would not work for you, because that config +causes git-annex to refuse to try to write to the remote. Which doesn't +tell you if your server is configured to correctly reject writes.) +"""]]